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I.  INTRODUCTION 


A.  BACKGROUND 

The  Defense  Modeling  and  Simulation  Office  (DMSO)  is  a  Department  of 
Defense  (DoD)  agency  which  serves  as  a  clearinghouse  for  modeling  and  simulation 
policies,  guidance,  and  activities.  It  acts  as  the  executive  secretariat  for  the  Executive 
Council  on  Modeling  and  Simulation  and,  among  other  specified  duties,  assists 
Department  of  Defense  (DoD)  Services  and  Agencies  develop,  acquire,  and  share 
modeling  and  simulation  (M&S)  technology,  standards,  and  processes. 

A  key  document  which  guides  DMSO's  activities  is  DoD  5000.59-P,  The  DoD 
Modeling  and  Simulation  Master  Plan,  dated  October  1995.  This  document  provides 
focus  and  direction  to  the  entire  DoD  M&S  community.  Its  six  objectives  address 
commonly  shared  concerns  such  as  a  common  technical  framework,  authoritative 
representations  of  the  natural  environment,  systems,  and  human  behavior,  and  M&S 
education,  resource  repositories,  and  accreditation. 

DMSO  responded  to  the  three  sub-objectives  of  the  Modeling  and  Simulation 
Master  Plan  depicted  in  Table  1  by  developing  the  Functional  Description  of  the  Mission 
Space  (FDMS)  Resource  Center.  The  Resource  Center,  at  its  most  basic,  is  a  web-based 
products  repository  which  allows  users  to  register,  control,  and  manage  their  digital 
models  and  simulations.  It  provides  analysis  tools,  and  can  facilitate  re-use  and 
interoperability  by  transforming  certain  products  into  XML  documents  using  a  standard 
document  type  definition  (DTD). 
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Sub-Objective 

Description 

1-2 

Develop  conceptual  models  of  the  mission  space 
(CMMS)  to  provide  a  common  starting  point  for 
constructing  consistent  and  authoritative  M&S 

representations,  and  to  facilitate  interoperability  and  reuse  of 

simulation  components. 

1-3 

Establish  data  standards  to  support  common 

representations  of  data  in  models  and  simulations. 

5-3 

Provide  a  repository  system  to  facilitate  developer 

and  end-user  access  to  modeling  and  simulation  resources. 

Table  1.  Selected  Sub-Objectives  from  DoD  5000. 59-P 


The  DoD  Modeling  and  Simulation  Master  Plan  is  almost  six  years  old.  It  is 
currently  being  updated  and  is  expected  to  be  approved  later  this  year.  The  new  plan  is 
anticipated  to  replace  the  current  six  main  objectives  with  the  five  objectives  listed  in 
Table  2.  The  FDMS  Resource  Center,  by  design,  actively  supports  the  first  and  fourth 
objectives. 


Objective 

Description 

1 

Promote  M&S  standardization  and  reuse 

2 

Develop  authoritative  M&S  representations 

3 

Provide  and  maintain  supporting  M&S  infrastructure 

4 

Provide  ready  access  to  M&S  resources 

5 

Improve  the  usability  of  M&S 

Table  2.  Main  Objectives  of  Draft  DoD  5000.59-P 
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DMSO  manages  a  related  but  separate  cataloging  effort  called  the  Modeling  and 
Simulation  Resource  Repository  (MSRR).  Whereas  the  FDMS  Resource  Center  is 
designed  to  catalog  military  models  of  the  mission  space,  provide  analysis  capabilities, 
and  promote  interoperability  and  re-use  through  a  standard  DTD,  the  purpose  of  the 
MSRR  is  to  catalog,  via  a  distributed  system  of  resource  servers,  all  products  related  to 
modeling  and  simulation.  These  products  include,  but  are  not  limited  to,  models, 
simulations,  databases,  algorithms,  documents,  tools,  and  utilities.  DMSO  is  currently 
orchestrating  an  effort  to  link  some  of  the  capabilities  of  the  MSRR  with  the  FDMS 
Resource  Center  in  order  to  reduce  redundancies  and  achieve  synergy  between  the  two 
systems.  In  fact,  some  of  the  requirements  discussed  in  Chapter  III  are  currently 
implemented  in  the  MSRR.  If  the  linkage  between  the  MSRR  and  the  FDMS  Resource 
Center  is  successful,  those  requirements  will  not  have  to  be  re-implemented  in  the  FDMS 
Resource  Center. 

B.  PURPOSE 

The  FDMS  Resource  Center  is  functional  and  on-line  at  http://38.24 1.48. 9.  It  is  a 
tool  provided  by  DMSO  for  the  use  of  the  Services'  and  Agencies'  modeling  and 
simulation  organizations.  There  is  no  requirement  that  the  Services  and  Agencies  use  the 
Resource  Center.  Therefore,  the  Resource  Center  will  only  provide  value  to  the  DoD  if 
the  Services  and  Agencies  recognize  that  value  and  choose  to  register  their  M&S 
products  with  the  Center  and  use  the  analysis  and  translation  tools  there. 

The  FDMS  Resource  Center  Project  Manager  (PM)  recognizes  the  synergy  which 
could  develop  if  most  DoD  M&S  organizations  used  the  Center.  To  that  end,  the  PM  is 
concerned  that  the  Resource  Center  be  intuitive  and  easy  to  use.  The  Resource  Center 
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provides  users  strict  control  of  the  products  they  register,  and  the  PM  wants  to  ensure  that 
the  workflow  which  makes  available  that  strict  control  to  be  clear  and  unambiguous. 

The  purpose  of  this  thesis  is  to  conduct  an  analysis  of  the  FDMS  Resource  Center 
and,  keeping  the  PM's  goals  in  mind,  provide  a  set  of  recommendations  -  herein  called 
"requirements"  -  which  will  enhance  the  Resource  Center's  ease  of  use  and  improve 
users'  perceptions  of  the  proven  capabilities  of  the  Center. 

C.  SCOPE  AND  METHODOLOGY 

This  thesis  concerns  itself  with  the  usability  of  the  FDMS  Resource  Center  web- 
based  tool.  It  does  not  take  into  account  the  kind  of  data  registered  or  stored  in  the 
Resource  Center's  repositories,  nor  does  it  assess  the  functionality  of  the  Center's  analysis 
tools  or  XML  translation  capability. 

The  author  developed  the  concept  for  this  thesis  after  an  initial  interview  with  the 
FDMS  Resource  Center's  project  manager,  Mr.  Jack  Sheehan.  Mr.  Sheehan  arranged  for 
the  author  a  workspace  in  the  offices  of  Resource  Center's  development  contractor. 
Innovative  Management  Concepts,  Inc.  (IMC)  of  Sterling,  VA.  At  IMC  he  was  able  to 
analyze  the  Resource  Center  on  IMC's  development  server,  read  development  documents, 
and  confer  daily  with  IMC's  project  manager  and  chief  programmer/developer.  From  this 
vantage  point  the  author  was  able  to  study  and  use  the  FDMS  Resource  Center  and 
develop  the  requirements  discussed  in  Chapter  3. 
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II.  OVERVIEW  OF  THE  FUNCTIONAL  DESCRIPTION  OF  THE 
MISSION  SPACE  RESOURCE  CENTER 


A.  DESCRIPTION  OF  FUNCTIONS 

The  FDMS  Resource  Center  provides  a  number  of  functions  to  the  M&S 
community,  to  include  search  capability  of  authoritative  data  sources,  guidance  on 
common  syntax  and  semantics,  and  links  to  other  M&S  web  sites.  The  main  attraction  of 
the  Resource  Center,  however,  is  its  FDMS  Library.  The  Library  consists  of  two  M&S 
repositories:  the  Native  Library  and  the  Common  Library.  Each  library  consists  of  digital 
modeling  and  simulation  products  of  the  U.S.  military's  functional  description  of  the 
battlespace. 

1.  Native  Library 

The  FDMS  Native  Library  consists  of  the  M&S  files  which  the  user  submits  to 
the  repository.  A  Native  Library  product  may  be  a  word  processor  file  describing  a  real- 
world  process,  a  set  of  slides  illustrating  an  IDEF  model,  or  executable  code.  The  digital 
models  and  simulations  are  stored  imchanged  from  their  original  form;  hence,  it  is  the 
Native  Library  because  the  files  are  maintained  in  their  native  format. 

This  is  not  to  say  that  the  files  are  fixed  in  the  Library  forever.  As  described 
below,  users  have  control  over  the  models  and  simulations  they  register  in  the  Library. 
Users  can  remove  from  the  Library  models  and  simulations  they  deem  obsolete  or  no 
longer  accurate.  Conversely,  a  user  can  modify  his  file  and  resubmit  it  so  that  it  replaces 
the  original  file  or  exists  with  the  original  file  providing  a  configuration  management  trail 
and  record. 
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The  Native  Library  contains  search  tools  to  enable  the  recovery  and  re-use  of 
existing  models  and  simulations.  It  also  provides  controls  with  which  the  originating  user 
can  regulate  the  use  of  his  products. 

2.  Common  Library 

The  FDMS  Common  Library  provides  the  FDMS  with  its  re-usability  and 
interoperability  functions.  Some  Native  Library  products  can  be  converted  into  a 
"common"  product  using  the  FDMS  XML  Data  Interchange  Format  (DIF)  and  then 
stored  in  the  Common  Library.  Models  and  simulations  in  the  structured  format  provided 
by  the  FDMS  XML  DIF  can  then  be  more  thoroughly  analyzed,  creditably  compared 
with  other  documents  in  the  same  format,  and  will  more  likely  interoperate.  The 
likelihood  of  reuse  of  developed  models  and  simulations  is  enhanced  as  well. 

As  with  the  Native  Library,  users  have  control  over  who  has  access  to  their  M&S 
products. 

B.  TYPES  OF  USERS 

The  FDMS  Resource  Center  defines  four  types  of  users  (not  including  the  FDMS 
Administrator  who  is  not  discussed  in  this  thesis)  as  shown  in  the  Resource  Center  screen 
shot  in  Figure  1 .  These  user  types  are  not  mutually  exclusive  -  every  Resource  Center 
user  can  act  as  a  Producer,  Consmner,  and  Examiner,  and  a  selected  few  are  designated  as 
Sponsors  as  well. 

1.  Sponsor 

The  Sponsor  is  the  kingpin  of  the  FDMS  Resource  Center.  Sponsors  are  assigned 
by  the  Resource  Center  Administrator  after  a  positive  check  with  the  potential  Sponsor’s 
organization  that  the  candidate  is  an  M&S  principal  who  requires  Sponsor  privileges. 
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Sponsors  not  only  have  control  of  who  has  access  to  FDMS  products,  but  they  also 
control  who  has  access  to  the  FDMS  libraries.  Through  the  use  of  privileges,  the  Sponsor 
approves  who  may  submit  M&S  products  (called  the  "Producer")  and  who  may  view  or 
use  them  (called  the  "Consumer").  He  may  also  assign  a  user  (called  the  "Examiner")  to 
review  or  analyze  a  product. 


Accr«dK 


I  CrnUfy 

I  Examiner 

Figure  1 .  Users  of  the  FDMS  Libraries. 

2.  Producer 

The  Producer,  of  course,  also  has  a  large  role  in  the  FDMS  Resource  Center  —  he 
submits  the  products  for  registration  and  inclusion  in  the  libraries.  The  Producer 
develops  the  products  outside  the  Resource  Center,  and  his  submissions  are  controlled  by 
a  governing  Sponsor. 
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3. 


Consumer 


The  Consumer  is  the  actual  user  of  an  M&S  product  registered  in  the  FDMS 
Resource  Center.  As  stated  above,  a  Consumer  can  gain  access  to  a  product  only  with  the 
explicit  permission  of  the  governing  Sponsor. 

4.  Examiner 

The  Native  and  Common  Libraries  provide  the  capability  for  the  Sponsor  to 
assign  a  product  to  a  user  for  that  user  to  analyze,  verify,  validate,  accredit,  or  certify. 
That  user,  when  he  gets  these  missions,  is  the  Examiner.  Some  tools  to  assist  in  these 
functions  are  provided  in  each  of  the  FDMS  libraries. 

C.  USE  CASES 

A  few  representative  use  cases  will  illustrate  the  relationship  the  different  users 
have  with  each  other  as  well  as  partially  demonstrate  the  need  for  the  requirements 
analysis  in  Chapter  III. 

1.  Register  a  Product 

The  first  use  case  describes  the  process  to  register  a  digital  product  in  the  FDMS 
Resource  Center. 

Use  Case:  Register  a  Product 

Actors:  Producer,  Sponsor,  Administrator 

Purpose:  To  provide  the  Resource  Center  a  digital  product. 

Overview:  Producer  provides  the  Resource  Center  a  link  to  a  digital  product. 

Sponsor  decides  to  accept  the  link,  which  constitutes  registering  the 
product. 
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Actor  Action 


System  Response 


1.  Producer  browses  through  available 
registration  elements  and  selects  one. 

2.  Producer  fills  in  descriptive  information 
and  provides  a  link  to  the  digital 
product. 

3.  Producer  clicks  button  uploading 
product. 

4.  Sends  message  notifying 

Administrator  of  Producer's  action. 

5.  Sponsor  selects  product  name  and  clicks 
button  approving  the  product. 

6.  Sends  message  notifying 

Administrator  of  Sponsor's  action. 

7.  Administrator  selects  product  name  and 
indicates  to  the  System  that  selection 
should  be  visible. 

8.  Makes  product  name  visible  to  all 
users  of  Sponsor's  registration 
element. 

This  use  case  describes  the  current  implementation  of  process  to  register  products 

in  the  FDMS  Resource  Center.  An  analysis  of  the  use  case  reveals  some  shortcomings. 
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First,  how  did  the  Sponsor  know  a  product  was  pending  his  decision?  The  System 
notified  the  Administrator  of  the  Producer's  actions,  but  it  did  not  notify  the  Sponsor. 
Second,  why  did  the  System  not  inform  the  Producer  of  the  Sponsor's  decision?  An 
alternative  scenario  to  this  use  case  occurs  when  the  Sponsor  disapproves  registering  the 
new  product.  In  either  case,  it  is  a  significant  oversight  not  to  notify  the  Producer  of  the 
outcome  of  his  initial  action. 

2.  Authorize  Release 

This  second  use  case  describes  the  fairly  simple  process  of  a  Sponsor  providing  a 
Consumer  access  to  a  Resource  Center  product. 

Use  Case:  Authorize  Release 

Actors:  Sponsor,  Consumer 

Purpose:  To  provide  a  Consumer  access  to  digital  products. 

Overview:  Sponsor  provides  access  to  a  product  or  a  registration  element 

(constituting  a  number  of  products)  to  a  Consumer  or  set  of  Consumers. 


Actor  Action 

1 .  Consumer  contacts  Sponsor  and  requests 
Consumer  privileges  for  a  Resource 
Center  product. 

2.  Sponsor  selects  product  name  or 
registration  element  (constituting  a 
range  of  products). 
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Actor  Action 


System  Response 


3.  Sponsor  selects  Consumer  name  jfrom  a 
drop-down  list  and  clicks  the  "Finish" 
button. 

4.  Makes  selected  product  or 
registration  element  visible  to 
Consumer.  Notifies  Consumer  via 
email  message. 


This  use  case  is  straight-forward  and  describes  a  critical  process  for  the  Resource 
Center  to  provide  utility  to  its  users.  But  consider  an  alternative  scenario  in  which  the 
Sponsor  agrees  to  provide  many  Consumers  access  to  a  product.  Step  3  then  becomes: 
"Sponsor  selects  each  Consumer  name  one  by  one  fi'om  the  drop-down  list.  Once 
complete,  Sponsor  clicks  the  'Finish'  button."  This  is  still  a  straight-forward  process 
unless  the  Sponsor  has  to  select  dozens  of  names  firom  the  list.  It  would  be  an  even 
greater  chore  if  the  names  were  unfamiliar  to  the  Sponsor,  e.g.,  the  Consumers  are  firom 
another  organization  which  has  an  interest  in  studying  or  reusing  the  Sponsor's  products. 

The  following  chapter  addresses  these  and  other  issues  with  the  FDMS  Resource 
Center.  The  intent  is  to  enhance  the  Resource  Center's  processes  so  that  they  will  be 
clear,  informative,  and  useful  to  the  DoD  modeling  and  simulation  community. 
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III.  REQUIREMENTS 


A.  INTRODUCTION 

This  chapter  defines  the  new  requirements  of  the  FDMS  Resource  Center.  The 
requirements  range  from  cosmetic  changes  of  existing  screens  to  refinements  of  current 
capabilities  to  definitions  of  entirely  new  FDMS  processes. 

In  general,  each  paragraph  of  this  section  describes  a  need  and  refers  to  a  figure 
which  illustrates  the  need.  The  resulting  requirement  is  labeled  with  an  “R”  followed  by 
a  hierarchical  number  (R3,  R3.1,  R3.1.1,  etc.)  and  separated  from  the  text  by  a  box.  All 
the  requirements  are  summarized  at  Table  3  at  the  end  of  this  chapter. 

B.  GENERAL  REQUIREMENTS 

The  FDMS  is  inconsistent  when  referring  to  the  digital  files  which  it  catalogs  and 
maintains.  At  times  the  files  are  called  “documents”,  “products”,  or  “resources”.  The 
term  “document”  is  ill-chosen  because  the  FDMS  hbraries  can  maintain  non-documents 
like  models  and  simulations  implemented  as  executable  files  or  databases.  The  term 
“resource”  is  not  concise  and  connotes  a  business-like  air  to  the  FDMS  tool  (funds,  assets 
and  liabilities,  income  and  expenditures,  etc.).  The  term  “product”  best  captures  the 
useful  nature  of  the  digital  files  maintained  and  cataloged  by  FDMS  libraries. 

R1  The  FDMS  libraries  will  refer  to  the  digital  files  in  its  repository  as 
“products”. 


13 


C.  PRODUCER  FUNCTIONS 

Producer  Functions  are  the  first  of  the  five  sets  of  user  functions.  The  set  of 
Producer  Functions  consists  of  four  subordinate  functions  as  depicted  in  Figure  2. 


Figure  2.  Producer  Functions. 

1.  Design/Create 

The  Design  and  Create  Documents  function  is  not  automated  in  FDMS.  The 
screen  (Figure  3)  clearly  states  that  the  user  must  create  documents  “external  to  the 
Toolset.”  This  information  is  useful  but  there  are  two  ambiguities  with  the  screen.  First, 
the  use  of  the  term  “documents”  is  misleading  but  has  already  been  discussed  in 
Paragraph  III. A  and  in  Requirement  Rl.  The  second  issue  centers  aroimd  the  terms 
“register”  and  “submit”.  In  FDMS,  to  “register”  a  product  is  to  initially  place  it  into  the 
repository.  Whenever  a  producer  modifies  an  FDMS  product,  he  has  to  “submit”  the 
modified  product  rather  than  re-register  it.  This  distinction  is  important  to  the  FDMS 
conununity  and  should  be  made  clear  either  explicitly  on  this  screen  or  through  a  direct 
link. 

R2  The  Design  and  Create  Documents  screen  will  clarify  the  difference 
between  “register”  and  “submit”. 
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Design  and  Create  Documents 


Defhvthr^: 

■  Qesign:  The  deit&^aie,  purposeful, 
pl^hg  to  descrte  a  model  ^  a 
scheme  forinplementation  of  the  model; 
to  defne  the  hterha!  elements  of  a  - 
•  •  model:  . 


(>jeate:  To  construct  a  resource;  to 
physically,  organize  hformatipn  recorded 
in  text.^  images  hto  a  deseed  fyrmat 


►  Native  Dqcu merits  are.  created  external  to  the.  Toolset.  You 
may  use  formats  such  as. Microsoft ’Word  document 
Microsoft  PowerPoint  Adobe  Acrobat; HTML,  XML., . 

►  Create  the  Document  using  a  desired  Tool,  '  ■ ' 

►'  When  you  are  ready  to  Register  or  Submit  the  Document  • . 
click  the  appropriate  button  from  the  Producer  Vievv.  menu  on  • 
the  left.  ,  •  , 


Figure  3.  Design  and  Create  Documents  Screen. 


2.  Register 

The  Register  New  Product(s)  function  constitutes  Producers’  requests  to  Sponsors 
to  load  and  maintain  products  in  the  FDMS.  It  has  two  sub-functions:  (1)  a  Producer  can 
create  a  registration  element  and  (2)  he  can  register  a  product, 
a.  Register  News  Products 

The  Register  New  Products  screen  (Figure  4)  suffers  from  a  lack  of 
clarity.  It  directs  the  Producer  to  “simply  upload”  a  product  or  to  create  a  hitherto 
imdefined  “registration  element.”  Neither  of  these  terms  are  defined  nor  can  their 
meanings  be  accurately  construed  from  the  context. 
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R3  The  Register  New  Products  screen  will  clearly  inform  the  user  of  his 
options  regarding  creating  registration  elements  or  registering  products. 


R3.1  The  screen  will  present  the  user  with  two  options:  to  register  a 
product  or  to  create  a  registration  element. 

R3.2  The  screen  will  briefly  define  “registration  element”  so  that  the 
user  can  make  an  informed  decision. 


Register  New  Pfpduct(s) 

Deiimthn:  The  fyrma!  deliv&y  of .3  resource  .  , 

.  fyr  actus!  hckjsion.hlhe  rqaositdry.  The  : 

Producer  has.  the  lead ro!e  to  register  anew 
resource  with  the  admtoistrator. 

•  Click  Here  to  simply  upload.your  document's). 

Click  Here  to  create  a  Registration  Element  before  uploading  your 
■  .  documerit(s).,  ,  '  , 

' 

Figure  4.  Register  New  Products  Screen. 

b.  Create  Registration  Element 

A  registration  element  is  analogous  to  a  directory  in  the  Unix  and  DOS  operating 
systems:  it  is  a  device  for  a  Producer  or  Sponsor  to  organize  his  modeling  and  simulation 
files.  Registration  elements  are  approved  by  Sponsors,  and  Sponsors  govern  what 
products  are  registered  and  “stored”  in  their  registration  elements. 

R4  The  FDMS  system  will  control  the  creation  of  registration  elements. 


16 


(1)  The  workflow  governing  the  creation  of  a  registration 
element  is  depicted  in  “as  is”  system  events  in  the  sequence  diagram  at  Figure  5.  A 
problem  with  the  workflow  occurs  in  the  first  step  when  the  Producer  creates  a 
registration  element.  He  does  not  request  the  creation  of  a  registration  element,  but 
actually  creates  one  on  the  system.  The  system  allows  the  Producer  to  create  his 
registration  element  as  a  sub-element  of  a  Sponsor’s  existing  registration  element  or 
imder  the  Administrator’s  root  registration  element.  A  Producer  can  immediately  start 
registering  his  products  under  the  new  registration  element  before  the  governing  Sponsor 
approves  it.  Clearly,  a  Producer  should  not  be  able  to  use  a  registration  element  before  it 
has  been  approved  by  the  Sponsor. 

R4.1  The  Producer  will  not  be  able  to  use  a  registration  element  and  it 
will  not  be  visible  to  users  other  than  the  Administrator  until  it  is 
approved  by  the  governing  Sponsor. 

(2)  A  second  problem  with  the  workflow  is  that  the  Sponsor 
is  not  automatically  informed  when  a  Producer  creates  a  registration  element.  Similarly, 
the  Producer  is  not  automatically  informed  when  a  Sponsor  approves  or  disapproves  a 
registration  element  the  Producer  created.  This  lack  of  notification  burdens  both  the 
Sponsor  and  the  Producer  to  manually  check  the  registration  status  of  the  elements  and 
products  they  oversee  or  are  interested  in. 

R4.2  The  FDMS  system  will  overtly  notify  the  governing  Sponsor  and 
Producer  during  the  various  steps  in  creating  a  registration  element  as 
depicted  in  the  sequence  diagram  at  Fig  5. 


17 


-  Solid  arrows  depict  “as  -is”  system  events 

-  Dashed  arrows  depict  “to-be”  system  events 


Figure  5.  Registration  Element  Creation  Sequence  Diagram. 

(3)  A  Producer  can  create  a  registration  element  by  completing 
the  screen  at  Figure  6.  The  screen  has  some  cosmetic  errors  in  it,  to  wit: 

•  The  header.  Register  Product(s),  and  definition  are  incorrect. 
This  screen  is  not  used  to  register  a  product  but  instead  is  used  to  create  a  registration 
element. 

•  The  term  “Registration  Element”  is  imderlined  suggesting  that 
it  is  a  hot-link  to  another  page.  It  is  not  and,  therefore,  is  potentially  confusing  to  the 
user. 
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•  Clicking  the  “Register”  button  in  the  top  right  comer  does  not 
complete  the  create-registration-element  process  as  does  the  “Register”  button  at  the 
bottom  of  the  screen.  It  instead  takes  the  user  back  to  the  previous  Register  New 
Products  screen. 


R4.3  The  Create  Registration  Element  screen  will  clearly  inform  the 
user  how  to  create  a  registration  element. 

R4.3.1  The  screen  will  have  a  clear  header  and  definition. 

R4.3.2  The  screen  will  not  have  misleading  underlining. 

R4.3.3  The  screen’s  top  “Register”  button  will  be  labeled  to 
reflect  its  trne  “go  back  one  screen”  function. 


c.  Register  Produces) 

The  process  for  a  Producer  to  register  a  product  mirrors  the  process  to 
create  a  registration  element  (Figure  5)  and,  as  such,  suffers  from  the  same  deficiencies: 
the  FDMS  system  fails  to  inform  the  Sponsor  when  a  Producer  submits  a  product  for 
approval  and  the  system  fails  to  notify  the  Producer  when  the  Sponsor  approves  or 
disapproves  a  product.  As  with  the  registration  element  process,  this  process 
unnecessarily  burdens  the  Sponsor  and  Producer  to  manually  check  the  FDMS  libraries 
for  product  status. 

The  Register  Product(s)  screen  is  straight-forward  and  clear  except  that  it 
shares  a  fault  of  the  Create  Registration  Element  screen  —  it  displays  a  deceptive 
“Register”  button  which  takes  the  user  back  to  the  previous  Register  New  Products 
screen. 
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Figure  6.  Create  Register  Element  Screen. 
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3.  Remaining  Producer  Functions 

The  remaining  two  of  the  four  Producer  functions  are  in  good  order.  The  third 
function,  Integrate/Modify,  is,  like  the  Design/Create  function,  not  automated.  The 
corresponding  Integrate/Modify  Documents  screen  instructs  the  user  to  modify  registered 
products  with  tools  “external  to  the  (FDMS)  toolset.”  The  instructions  are  clear.  The 
title  of  the  screen,  however,  should  change  “Documents”  to  “Products”  as  noted  in 
Requirement  R1 . 

The  fourth  Producer  function,  Submit,  instructs  the  user  how  to  re-register  a 
product  which  has  been  modified.  This  function  and  its  corresponding  screen  are  clear. 

D.  SPONSOR  FUNCTIONS 

The  Sponsor,  acting  as  the  “traffic  cop”  in  the  FDMS  libraries,  controls  the 
registration  and  access  of  products.  To  do  this  the  libraries  provide  the  Sponsor  with  four 
functions  as  depicted  in  Figure  7.  The  functions  are  similar  in  that  they  entail  the 
Sponsor  selecting  names  of  products  for  approval  or  endorsement  or  selecting  names  of 
users  for  specific  permissions  to  view  or  effect  the  products. 


j 

1 

i 

Approve  1 

s 

I 

H 

i 

1 

Endorse  h 

1 

I 

I 

Allocate  1 

1 

I 

Authorize  Release  ■ 

Figure  7.  Sponsor  Functions. 
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1.  Approve 

The  Product/Registration  Element  Approval  screen  (Figure  8)  is  functional 
although  aspects  of  it  are  misleading.  Notably,  the  title  of  the  screen  is  incorrect  -  this 
screen  is  used  to  approve  products  as  well  as  registration  elements.  This  error  repeats 
itself  in  the  table  which  displays  “Registration  Element”  as  the  first  column’s  header 
when  that  column  lists  both  registration  elements  and  products.  Less  serious,  but  still 
potentially  puzzling  to  the  novice  Sponsor,  is  the  second  column’s  header,  “User”.  In 
fact,  the  only  user  of  the  screen  is  one  who  can  approve  or  disapprove  registration 
elements  and  products;  that  is,  a  Sponsor.  The  column  header  should  reflect  as  much. 

R6  The  Product/Registration  Element  Approval  screen  will  be  clear. 

R6.1  The  screen  header  will  be  correctly  labeled. 

R6.2  The  headers  of  the  first  and  second  columns  of  the  approval  table 

will  read  “Product/Registration  Element”  and  “Sponsor”,  respectively. 


Figure  8.  Product/Registration  Element  Approval  Screen. 
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2. 


Endorse 


The  Product/Registration  Element  Endorsement  screen  (Figure  9)  is  nearly 
identical  to  the  Product/Registration  Element  Approval  screen  and  has  similar 
deficiencies.  The  title  of  the  screen  does  not  reflect  that  registration  elements  are  also 
endorsed  on  this  screen.  Additionally,  two  columns  in  the  table  are  mis-labeled:  the 
“User”  column  should  be  named  “Sponsor”  and  the  “Approved”  column  should  be 
named  “Endorsed.”  These  changes  will  improve  clarity  and  minimize  confusion. 

R7  The  headers  of  the  second  and  third  columns  of  the  approval  table  in  the 
Product  Endorsement  screen  will  read  “Sponsor”  and  “Endorsed”,  respectively. 


Product  Endorsement 

Defimtion:  To  approve  of  a  resource. that  wss  produced  under. the  au^ic^' of  another. sponsor  , 


r  Reglstratlori'El^eriiff^c^ 

''U 

"  Comment  -  - 

Test  Registration  Element  2 

Natnaiie  Mbi^Ella  i  Ufl 

2001'02*20  19:34:35 

1  am  just  testing 

Test  Registration  Element  2b 

Nathalie  Mbida-Elia 

Si 

2001-03-26  11:59:17 

Test 

Test  Registration  Eiement  2b1 

Bill  Deng 

Si 

2001-04-2517:03:36 

test  comments. 

Test  Registration  Element  2c 

Test  Registration  Element  2d 

HHHHH 

HHHHHHHHHHIH 

A  Test 

HHliHiHl 

IBHHHHi 

IIIIIBHHHHHHHHHH: 

NLE  001  Name 

n 

LBidorse  ^ . 


Hi^light  the  prodxtycxj  wi^.  to  Endorse  on  the  grid  above,  then  cHck  on  the  •“Endorse"  • 
button  located  below;  th^^  •  •' 


Figure  9.  Product/Registxation  Element  Endorsement  Screen. 
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3.  Allocate  and  Authorize  Release 

The  Product  Allocation  and  the  Product  Release  Authorization  functions  are 
similar;  they  both  allow  the  Sponsor  to  assign  privileges  to  users  regarding  the  use  of 
products  under  the  purview  of  the  Sponsor.  (There  is  a  distinct  difference  between  the 
two  screens.  The  Product  Allocation  screen  allows  the  Sponsor  to  assign  Sponsor, 
Examiner,  and  Producer  permissions  to  users.  The  Product  Release  Authorization  screen 
only  allows  the  Sponsor  to  provide  access  to  a  product  (view  or  copy  privileges)  to  a 
Consumer.)  The  screens  are  functional  and  clear  (the  Product  Allocation  screen  is  shown 
at  Figure  10).  A  significant  capability  which  these  functions  lack,  however,  is  the  ability 
to  assign  privileges  to  a  group  of  users. 


Product  Allocation 

,  Deikuthn:  To  Assign  the  tesks  of  administratk^,  production^  examSiation,  ard  consurrption  of  a  resource  tn- specific  groipe/hdividuafs 


■  Refllsli^on  BementiProtJuot' 

-T-ExamlTOr;-'" 

4 

Test  Registration  Element  2 

Bill  Deng 

2001-03-18  14:29:56 

Sj 

Si 

sr 

Daniel  P.  Sagan 

2001-03-22  16:32:47 

□ 

Si 

Si 

Jim  Lin 

2001-03-1614:29:57 

Si 

Bj 

sr 

Kit  Case 

2001-03-16  14:29:56 

Si 

Sf 

sr 

Patrick  Michael  Humphrey 

2001-03-22  16:32:47 

□ 

B! 

sr 

Paul  M  Nelson 

2001-04-11  14:48:27 

Si 

sr 

sr 

Wayne  Randolph 

2001-03-16  16:31:14 

□ 

Si 

sr 

Test  Registration  Element  2b 

Bill  Deng 

2001-04-26  09:45:13 

□ 

Si 

□ 

Nathalie  Mbida-Ella 

Si 

m 

sr 

Test  Registration  Element  2b1 

Nathalie  Mbida-Ella 

2001-04-11  17:37:35 

□ 

Si 

□ 

£l 

^  AlIbcatE'l, 

.  _J 

■  -id 

^  /  Hi 

ghlight  the  product  you  wish  to  Allocate  on  the  grid  above,,  then  click  on  the  “Allocate" 

button  located  below  the  grid. 


Figure  10.  Product  Allocation  Screen. 
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FDMS'  current  capability  allows  the  Sponsor  to  assign  privileges  to  only  one  user 
at  a  time.  This,  of  course,  is  not  a  burden  to  a  Sponsor  who  has  only  a  small  number  of 
users  interested  in  his  products.  A  Sponsor  with  a  large  team,  however,  will  have  a 
somewhat  inconvenient  chore  assigning  privileges,  one  after  the  other,  to  his  team. 

Consider  a  hypothetical  example:  The  manager  of  a  new  Army  missile  program 
contacts  the  Defense  Threat  Reduction  Agency  (DTRA).  He  knows  that  DTRA  has 
developed  a  computer  model  -  registered  in  FDMS  ~  which  displays  the  downwind 
hazard  of  chemical  agents  by  predicting  surface  winds  and  weather  over  the  local  terrain. 
The  missile  PM  is  interested  in  the  wind  predictive  capabilities  of  the  DTRA  model  for 
possible  reuse  in  a  simulation  the  missile  PM  is  building  to  predict  the  accuracy  of  the 
missile.  He  asks  the  DTRA  PM  to  allocate  consiuner  privileges  to  fifty  members  of  the 
missile  program's  team.  As  shown  in  Figme  11,  the  DTRA  PM  will  have  to  scroll 
through  the  entire  list  of  FDMS  users  and  individually  pick  out  fifty  unfamiliar  names. 
That  would  be  quite  a  chore,  and  entirely  avoidable  if  the  missile  PM  was  able  to  group 
his  team  under  the  name  MSL_SIM,  for  example.  Then  the  DTRA  PM  would  only  have 
to  pick  one  name  off  the  list,  and  go  on  with  his  business. 

Clearly,  then  a  Sponsor  needs  to  be  able  to  create  groups  of  users  and  assign 
privileges  to  the  those  groups.  This  leads  to  the  next  set  of  requirements  found  on 
page  23: 

As  of  this  writing,  the  subordinate  requirements  of  Requirement  R8.1  are  met  in 

the  Modeling  and  Simulation  Resource  Repository  (MSRR).  As  discussed  in  the 

Introduction,  the  MSRR  is  a  separate  but  related  modeling  and  simulation  library 

developed  and  managed  by  the  Defense  Modeling  and  Simulation  Office.  There  is  an 
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effort  currently  underway  which,  if  successful,  will  allow  the  FDMS  to  use  groups 
created  and  maintained  in  the  MSRR.  If  that  effort  is  unsuccessful  or  caimot  be 
implemented  in  a  timely  manner,  the  grouping  requirements  will  have  to  be  implemented 
directly  into  FDMS. 


T p  confirm  that  you  want  to  Release:  T Re^tratipn  fiement  2b  1, 
please  complete  the  following'  information  then  dick  on  the  "Finish"  button! 


You  want  to  Release  these  access  privieg^ 

CONSUMERrAccess^S 

CONSUIMER:  Locate  ri:  . 
CONSUMER:  Review 

jd  ■ , 

To. the  following  users: 

Case,  Kit  1 

Chang,  Angela  0 

Deng,  Bill  ' 

Dou^erty,  Fran  , 

Dowd,  Mary  Kate  Si  .  . 

. .  . . ■3 

Your  Comments  (if  any)...-  .  , 

Jll 

Figure  1 1 .  Product  Release  Screen. 
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R8  A  Sponsor  will  be  able  to  define  groups  and  assign  privileges  to  those 
groups. 


R8.1  A  Sponsor  will  be  able  to  create  and  modify  groups. 

R8.1.1  Each  group  will  have  a  unique  name. 

R8.1.2  The  Sponsor  will  have  the  option  to  add  notes  or 
explanatory  comments  about  a  group. 

R8.1.3  The  system  will  display  the  names  of  users  so  that  the 
Sponsor  can  select  user  names  from  the  display  to  be  members  of 
his  group. 

R8.1.4  A  Sponsor  will  have  the  option  of  allowing  other  users  to 
use  his  group  or  of  restricting  all  other  users  from  using  his  group. 

R8.1.5  A  Sponsor  will  be  able  to  modify  a  group  he  created.  He 
will  be  able  to  change  a  group's  name,  update  the  notes  about  a 
group,  add  or  delete  members  from  the  group,  and  change  the 
restrictions  governing  others'  use  of  the  group. 

R8.1.6  Only  the  original  Sponsor  and  the  Administrator  will  be 
able  to  modify  or  delete  a  group. 

R8.2  A  Sponsor  will  be  able  to  assign  FDMS  privileges  to  a  group  in  the 
same  manner  as  he  would  to  an  individual  user. 
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E.  REQUIREMENTS  SUMMARY 


Table  3  summarizes  the  requirements  enumerated  in  this  chapter.  The  author 
strongly  believes  that  the  implementation  of  these  requirements  into  subsequent  versions 
of  the  FDMS  Resource  Center  will  significantly  improve  the  usability  of  the  web-based 
repository.  This,  in  turn,  will  encourage  members  of  the  DoD  modeling  and  simulation 
community  to  exploit  the  Resource  Center  by  registering  and  analyzing  their  own 
products  in  the  repository  and  by  reusing  other  registered  products.  This  anticipated 
synergy  will  directly  support  the  first  and  fourth  objectives  of  the  draft  DoD  Modeling 
and  Simulation  Master  Plan  (see  Table  2). 


R1 

The  FDMS  libraries  will  refer  to  the  digital  files  in  its  repository  as 

“products.” 

R2 

The  Design  and  Create  Documents  screen  will  clarify  the  difference 
between  "register"  and  "submit." 

R3 

The  Register  New  Products  screen  will  clearly  inform  the  user  of  his 
options  regarding  creating  registration  elements  or  registering  products. 

R3.1 

The  screen  will  present  the  user  with  two  options:  to  register  a 
product  or  to  create  a  registration  element 

R3.2 

The  screen  will  briefly  define  "registration  element"  so  that  the 

user  can  make  an  informed  decision. 

Table  3  Requirements  Summary  (Part  1  of  3) 
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R4 

The  FDMS  system  will  control  the  creation  of  registration  elements. 

R4.1 

The  Producer  will  not  be  able  to  use  a  registration  element  and  it 

will  not  be  visible  to  users  other  than  the  Administrator  xmtil  it  is 

approved  by  the  governing  Sponsor. 

R4.2 

The  FDMS  system  will  overtly  notify  the  governing  Sponsor  and 

Producer  during  the  various  steps  in  creating  a  registration 

element  as  depicted  in  the  sequence  diagram  at  Fig  5. 

R4.3 

The  Create  Registration  Element  screen  will  clearly  inform  the 

user  how  to  create  a  registration  element. 

R4.3.1 

The  screen  will  have  a  clear  header  and  definition. 

R4.3.2 

The  screen  will  not  have  misleading  underlining. 

R4.3.3 

The  screen’s  top  “Register”  button  will  be  labeled  to  reflect 

its  true  “go  back  one  screen”  function. 

R5 

The  FDMS  system  will  control  the  submission  of  products  for  approval. 

R5.1 

The  system  will  overtly  notify  the  governing  Sponsor  and 

Producer  during  the  various  steps  in  the  submission  of  products 

for  approval 

R5.2 

The  top  "Register"  button  on  the  Register  Product(s)  screen  will  be 

labeled  to  reflect  its  true  "go  back  one  screen"  function. 

R6 

The  Product/Registration  Element  Approval  screen  will  be  clear. 

R6.1 

The  screen  header  will  be  correctly  labeled. 

R6.2 

The  headers  of  the  first  and  second  columns  of  the  approval  table 

will  read  "Product/Registration  Element"  and  "Sponsor", 

respectively. 

Table  3  Requirements  Summary  (Part  2  of  3) 
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R7 

The  headers  of  the  second  and  third  columns  of  the  approval  table 

in  the  Product  Endorsement  screen  will  read  "Sponsor"  and 

"Endorsed",  respectively. 

R8 

A  Sponsor  will  be  able  to  define  groups  and  assign  privileges  to 

those  groups. 

R8.1 

A  Sponsor  will  be  able  to  create  and  modify  groups. 

R8.1.1 

Each  group  will  have  a  unique  name. 

R8.1.2 

The  Sponsor  will  have  the  option  to  add  notes  or 

explanatory  comments  about  a  group. 

R8.1.3 

The  system  will  display  the  names  of  users  so  that 
the  Sponsor  can  select  user  names  from  the  display  to 

be  members  of  his  group. 

R8.1.4 

A  Sponsor  will  have  the  option  of  allowing  other 
users  to  use  his  group  or  of  restricting  all  other  users 

from  using  his  group. 

R8.1.5 

A  Sponsor  will  be  able  to  modify  a  group  he  created. 

He  will  be  able  to  change  a  group's  name,  update  the 

notes  about  a  group,  add  or  delete  members  from  the 
group,  and  change  the  restrictions  governing  others' 

use  of  the  group. 

R8.1.6 

Only  the  original  Sponsor  and  the  Administrator  will 

be  able  to  modify  or  delete  a  group. 

R8.2 

A  Sponsor  will  be  able  to  assign  FDMS  privileges  to  a  group 

in  the  same  maimer  as  he  would  to  an  individual  user. 

Table  3  Requirements  Summary  (Part  3  of  3) 
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IV.  DISCUSSION  AND  CONCLUSION 


A.  DISCUSSION 

The  FDMS  Resource  Center  is  not  an  immature  product.  Select  organizations, 
such  as  the  Army’s  One  Semi- Automated  Forces  (OneSAF)  project  team,  are  beginning 
to  use  the  Resovurce  Center  extensively.  The  OneSAF  team,  for  example,  is  charged  to 
develop  a  computer-generated  force  (CGF)  which  can  simulate  a  full  range  of  military 
operations  at  the  battalion  and  brigade  levels.  The  purpose  of  the  CGF  is  to  test  ideas  and 
concepts  in  the  development  of  future  force  structures,  doctrine,  and  equipment. 
OneSAF  uses  the  FDMS  to  catalog  the  various  models  it  develops  or  acquires,  to  verify 
and  validate  those  models,  and  to  convert  selected  models  into  XML  products  using  a 
common  data  interchange  format.  These  “common”  models  can  then  interoperate  and 
grow  to  form  more  complex  and  faithful  models. 

Other  DoD  organizations  can  use  the  FDMS  Resource  Center  as  well,  but  as 
stated  earlier,  they  are  not  required  to  use  it.  Encouraging  the  use  of  the  Resource  Center, 
and  gaining  the  synergies  borne  of  commonly-formatted,  interoperable  models,  is  largely 
a  marketing  chore  which  DMSO  must  pursue  within  the  modeling  and  simulation 
community.  But  it  is  also  a  matter  of  providing  ready  access  to  a  repository  which  is  easy 
to  use  with  intuitive  and  self-explanatory  screens  and  applications.  It  is  this  second  issue 
which  this  work  attempts  to  address. 

The  author  took  the  role  of  the  requirements  analyst.  Over  a  period  of  six  weeks 
of  mostly  full-time  work  he  studied  the  operation  of  the  Resource  Center,  interviewed  the 
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functional  proponent,  and  had  numerous  discussions  with  the  project  manager  and  the 
lead  designer/programmer.  The  product  of  this  work,  and  the  subsequent  implementation 
of  it  into  the  Resource  Center  code,  will  favorably  impact  screen  design,  workflow,  and 
user  security  and  access. 

B.  CONCLUSION 

Defining  requirements  in  a  clear  and  unambiguous  style  is  the  first  step  in 
software  development.  Although  not  drafted  in  a  formal  way,  the  requirements  listed 
here  are  based  on  the  FDMS  Resource  Center  and  the  MSRR,  each  of  which  constitutes 
the  ultimate  in  formal  models  -  an  existing  implementation  of  a  software  product.  The 
requirements,  therefore,  are  easy  to  understand  within  the  context  of  the  existing  FDMS 
Resource  Center  and,  the  author  hopes,  will  not  be  difficult  to  implement.  Doing  so 
should  significantly  improve  a  novice  user’s  imderstanding  of  the  organization  and 
functionality  of  the  FDMS  Resource  Center. 

There  is  further  work  available  to  improve  and  broaden  the  functionality  of  the 
Resource  Center.  Of  particular  note  is  the  system’s  email  notification  system  referenced 
in  Figure  5  —  the  messages  themselves  could  be  made  more  clear  to  the  message 
recipients.  Examiner  functions,  to  include  the  analysis  tools  available  in  the  Common 
Library,  deserve  additional  scrutiny  and  optimization.  Finally,  a  closer  linkage  with  the 
MSRR  may  be  possible  and  desirable  to  expand  the  pool  of  the  Resource  Center’s  users. 
Improvements  and  expanded  functionality  in  these  areas  can  only  improve  the  potential 
the  FDMS  Resource  Center  holds  for  the  DoD  modeling  and  simulation  community. 
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